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(54) Title: X.500 SYSTEM AND METHODS 
(57) Abstract 

The present invention addresses the problem of imple- 
menting X.500 using an SQL product. The present applica- 
tion discloses an application of X.500 to a relational data- 
base, a database design and use of the database to perform 
X.500 services. Particularly, the disclosure relates to imple- 
mentation using an RDBMS (Relational DataBase Manage- 
ment System). One invention disclosed resides around ser- 
vice modelling, the processing of arbitrary data using a fixed 
set of queries/services. Another invention resides in the im- 
plementation of a disk based model using relational queries 
to satisfy X.500 services and enables benefits of RDBMS to 
be exploited. Further, the invention provides an SQL based 
X.500 application that can perform at subsecond speed and 
is relatively unaffected by the size of database, DIT shape, 
type of data or complexity of service, including aliases. 
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X.500 SYSTEM AND METHODS 

FIELD 

The present invention is directed to application of X.500 to a relational 
database, a database design and use of the database to perform X.500 
5 services. Particularly, the present invention is directed to implementation using 
a RDBMS (Relational Database Management System). The present invention is 
also directed to table structure and methods of operation of a database 
application. 
PRIOR ART 

10 X.500 is the International Standard for Electronic Directories [CCITT89J. 

These standards define the services, protocols and information model of a very 
flexible and general purpose directory. X.500 is applicable to information 
systems where the data is fairly static (e.g. telephone directory) but may need to 
be distributed (e.g. across organisations or countries), extensible (e.g. store 
1 5 names, addresses, job titles, devices etc.), object oriented (i.e. to enforce rules 
on the data) and/or accessed remotely. 
Relational Database Mananem ent System 

(RDBMS) provide facilities for applications to store and manipulate data. 
Amongst the many features that they offer are data integrity, consistency, 
20 concurrency, indexing mechanisms, query optimisation, recovery, roll-back, 
security. They also provide many tools for performance tuning, import/export, 
backup, auditing and application development. 

RDBMS are the preferred choice of most large scale managers of data. 
They are readily available and known to be reliable and contain many useful 
25 management tools. There is a large base of RDBMS installations and therefore 
a large amount of existing expertise and investment in people and procedures 
to run these systems, and so data managers are looking to use this when 
acquiring new systems. Most relational database products support the industry 
standard SQL (Structured Query Language). 
30 There has also been a move towards Object Oriented systems which 

provide data extensibility and the ability to handle arbitrarily complex data items. 
In addition, many corporations and government departments have large 
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information about each directory object, and is also incomplete in its 
implementation of X.500. 

This approach has been discredited by a number of text books and 
knowledge in the art, such as "Object-Oriented Modeling and Design" by J. 
5 Rumbaugh, et al, 1991, ISBN 0-13-630054-5, in which at paragraph 17.3.8 it is 
clearly stated that "putting all entities in the one table is not a good approach to 
relational database design". 

SUMMARY OF IN VENTIONS 

An object of the present inventions is to address the problem of 
10 implementing X.500 in a RDBMS which supports SQL or any other relational 
language. 

The present application seeks to disclose a number of inventions related 
to the implementation of X.500 standards in a RDBMS which supports SQL or 
any other relational language. 

15 The scope of the present invention is outlined in this specification, 

including the claims. 

In this document, at the time of filing, SQL is the most popular relational 
language and although it is only one form of relational language, the intent of 
the present invention is to have application to any other form of relational 
20 language, not just SQL. 

These inventions can be related to the following headings: 

1. Principle Design 

2. Conceptual Design 

3. Conceptual Method(s) 
25 4. Logical Design 

5. Logical Method(s) 

6. Physical Design 

7. Example Implementation 

The X.500 standard in no way dictates how the directory is to be 
30 implemented, only its capabilities and behaviour. One key to solving the 
implementation problem is the realization that X.500 defines a fixed set of 
services (e.g. Add, Modify, Search etc.) that can operate on arbitrary data. 
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the ability to create X.500 databases of far greater size than previously 
possible, without compromising performance or robustness. The 
databases can be small or large (250,000, 1 million or more entries), 
an optimal table design minimises wastage of disk space. 
5 • the ability to leverage off hundreds of man years of relational database 
developments and use "industrial strength" databases with proven 
reliability, integrity, security and tools for developing high performance 
applications. 

Based on this unique approach, the following disclosure will detail a 
10 number of inventions in an order with reference to Figures 2A and 2B, which 
illustrates schematically an overview of the present X.500 system. The table 
and column, names, order of columns and numeric values disclosed are given 
on an arbitrary basis in the overview. The number of columns disclosed 
represent a preferred operable requirement. Additional columns do not alter the 
1 5 use of the table as herein contemplated. 
1+ PRINCIPLE DFSIfiN 

The X.500 prior art attempts at implementation have been unable to 
overcome the relatively basic structural and operational differences between the 
X.500 requirements and functionality and SQL. The X.500 standard has a 
20 particular structure by nature, whereas SQL is designed to operate on relational 
structured tables. 

For a typical relational database application, the nature of data is well 
known, i.e. tables will consist of a number of columns and each column contains 
data relating to a particular data type (see Table B1). The different data types 
25 that can be stored is limited to the columns of the table. The data types are also 
limited to the types supported by the database (e.g. string, numeric, money, 
date). The database may also store data of a form not understood by the 
database per se, but understood by the application e.g. binary data. 



Name 


Surname 


Title 


Phone 


Chris 
Alana 


MASTERS 
MORGAN 


Sales Manager 
Sales Support 


03 727-9456 
03 727-9455 



Table B1: Employee Table 
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d. performance - if index is put on the type column, then each and 
every type is indexed. 
2. CONCEPT! iai r>P.Qi^ N 

The prior art has had difficulty in implementing X.500 as it has not been 
5 structured for extensibility, object oriented and hierarchy which are requirements 
of X.500. 

This is addressed, in one form, by functionally decomposing the 'property 
table" and thus resulting in what is called the Conceptual Design. 
The conceptual design resides in providing at least one of: 
10 1 - Attribute table, where extensibility is addressed by allowing the 

definition of a new attribute type in this table by adding a row to the 
table; 

2. Object table, which defines the attributes within each object; and/or 

3. Hierarchy table, which defines the relationship between the 
1 5 objects. 

In another invention, this problem is addressed by providing table 
structures in accordance with those disclosed in Figures 2A and 2B. 

Yet further inventions reside in addressing problems of data tolerance by 
providing in the present X.500 system for the replacement of the Value' column 
20 of the object table with value 'norm' and value 'raw' columns and/or replacing 
the RDN column in the hierarchy table with 'name norm' and 'name raw' 
columns. 

Further, the difficulty in prior art of accommodating aliases is addressed in 
the present X.500 system by providing an 'alias* column in the hierarchy table. 
25 The 'alias' column is flagged to indicate that, that entry is an alias. 

Further refinement may be provided by replacing the 'alias' column with 
alias and A-EID columns. The A-EID provides information about where the alias 
points. 

Still further refinement may be provided by replacing the 'parent' column 
30 in the hierarchy table with 'parent' and 'path' columns. 

The 'path' addresses the problem of implementing X.500 search, with 
aliases and subtrees. The 'path' has at least two unique properties: a) to 
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(speed, size) and secondary indexes may have large overheads 
(speed, size). 

2. Enable data in tables to be clustered. Clustering occurs as a result 
of its primary key (storage structure) and thus data may be 

5 organised on disk around its key. E.g. for the 'search' table, 

surnames may be clustered together 

3. Management - smaller tables are easier to manage, e.g. faster to 
update indexes, collect statistics, audit, backup, etc. 

4. Reduced I/O - speed improvements due to smaller rows, means 
10 more rows per page and thus operations perform less l/O's. 

5, LOGICAL METHODS 

A number of unique methods of interrogating the logical design tables are 
disclosed in the detailed description following. 

In addition, one method resides in caching the attribute table. Thus, (with 
15 the exception of initial loading) no SQL statements are issued to the database. 
In the present X.500 system, conversions are performed in memory. This 
provides a substantial speed advantage. 

Further, validation is performed in memory which avoids database roll- 
back. Roll-backs are time and system consuming. 
20 Still further, for the arbitrary filter, a dynamic SQL equivalent is built. This 

enables arbitrary complexity in X.500 searches. 

Also for search results, the present system utilizes set orientation queries 
of SQL to avoid 'row at a time' processing. Thus search results may be 
assembled in parallel in memory. 

25 & PHYSIRAI DFSinN 

New tables and new columns are introduced to overcome column width 
and key size restrictions and to achieve space optimisations. 

The following text is a disclosure of embodiments of the inventions 
outlined: 

1, PRINCIPI F PFftlON 

With reference to Figure 2A ( the principle design addresses the basic 
30 problem of representing the extensible, object oriented and hierarchical nature 
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will be NULL). Also, the data types are limited to the types supported by the 
database (e.g. string, numeric, money, date, etc.). 

The solution is to treat the data types as generic. The present invention 
adopts the method of representing arbitrary attributes (e.g. XOM [X/OPEN Object 
5 Management] API [Application Programming Interface]) as a type, syntax, value 
combination (see Table 1.1c) 



type 


syntax 


value 


Name 


String 


Chris 


Surname 


String 


MASTERS 


Title 


String 


Safes Manager 


Phone 


Numeric 


03 727-9456 


Mobile 


Numeric 


018 042671 



Table 1.1c - Representing arbitrary attributes 



1.2 Object OriflHtft 1 ? 

X.500 defines objects (e.g. people, organizations, etc.) which may contain 
an arbitrary number of "attributes". Since many objects must appear in the table 
a mechanism is required to distinguish each object. An "object name" column is 
added to the table for this purpose (see Table 1 .2a). 



15 



object name 


type 


syntax 


value 


Chris Masters 


Name 


String 


Chris 


Chris Masters 


Surname 


String 


MASTERS 


Chris Masters 


Title 


String 


Sales Manager 


Chris Masters 


Phone 


Numeric 


03 727-9456 


Chris Masters 


Mobile 


Numeric 


018 042671 


Alana Morgan 


Name 


String 


Alana 


Alana Morgan 


Surname 


String 


MORGAN 


AJana Morgan 


Title 


String 


Sales Support 


Alana Morgan 


Phone 


Numeric 


03 727-9455 



Table 1.2a - Representing objects with arbitrary values 



The above method allows any number of attributes to be assigned 
(related) to an entry. These attributes could be of arbitrary complexity (e.g. a 
multi-line postal address could be handled). As the number of columns is fixed 
new attributes can be added to any object without having to redefine the 
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Note that the root of the tree has no parent. Thus, if both Chris and Alana 
work for Datacraft and Datacraft is a child of the root then we can say that Chris 
and Alana are children of Datacraft and that Datacraft is the parent of Chris and 
Alana. 

2. CONCFPTUAL DFfilfiN 

In Section 1 it was shown that a single Property Table could represent the 



object 


parent 


type 




value 


name 


name 




syntax j 





10 



15 



With reference to Figure 2A in this section it will be shown that full X.500 
functionality can be represented by using three tables as shown below (see 
Table 2b and Figure 2A). 

Hierarchy Table 

| eip | Parent { Path [ Alias J A_EID | NameNorm | Namely [ 

Object Table 

eid j aid j vid | pistlng I ValueNorm | ValUem 



<aw 



Attribute Table 
"aid 



Type 



Syntax 



I 



Objectld 



Table 2b - Full Conceptual Design 

The conceptual design addresses major problems with implementing full 
20 X.500 functionality in relational tables. As each major design issue is presented, 
examples are provided to illustrate the solution. 
2.1 Functional Pecompositinp 

The Property Table (Figure 2A) can be decomposed into separate tables 
that reflect the hierarchical, object oriented and extensible nature of X.500, 
25 preferably as follows; 

a Hierarchy Table which defines the structural relationship between 
objects. 

an Object Table which defines the attribute values within each object, 
an Attribute Table which defines the different attribute types. 
These tables result from a process called functional decomposition. 
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2 2 X.SnnAttiihiitftft 

X.500 attributes have a protocol identifier which is transferred when any 
data is communicated between end systems. These identifiers are 
internationally defined and are called OBJECT IDENTIFIERS (e.g. 2.5.4.4 
5 means a surname string). Thus an "Objectld" column can be added to the 
Attribute table so that conversions between X.500 object identifiers and the 
internal attribute identifiers can be performed. 

In addition, X.500 allows an attribute to have an arbitrary number of 
values (e.g. the mobile phone could be treated just as a second telephone 
1 0 number). Thus a "value identifier or VID is introduced to identify values within 
an attribute in the Object Table. 

Hierarchy Table 



EID 


Parent 


Name 


10 


0 


Datacraft 


30 


10 


Chris Masters 


31 


10 


Alana Morgan 



Object Table 



EID 


AID 


VID 


Value 


10 


10 




Datacraft 


10 


16 




PO Box 123 CROYDON 


30 


3 




Chris 


30 


4 




MASTERS 


30 


12 




Sales Manager 


30 


20 




03 727-9456 


30 


20 




018 042671 


31 


3 




Alana 


31 


4 




MORGAN 


31 


12 




Sales Support 


31 


20 




03 727-9455 
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Object Table 



EID 


AID 


VID 


Disting 


Value 


10 


10 


1 


1 


Oatacraft 


10 


16 


1 


0 


PO Box 123 CROYDON 


30 


3 


1 


1 


Chris 


30 


4 




1 


MASTERS 


30 


12 




0 


Sales Manager 


30 


20 




0 


03 727-9456 


30 


20 




0 


018 042671 


31 


3 




1 


AJana 


31 


4 




1 


MORGAN 


31 


12 




0 


Sales Support 


31 


20 


1 


0 


03 727-9455 



Attribute Table 



AID 


Type 


Syntax 


Objectld 


3 


Name 


string 


2.5.4.3 


4 


Surname 


string 


2.5.4.4 


10 


Organization 


string 


2.5.4.10 


12 


Title 


string 


2.5.4.12 


16 


Postal Address 


address string 


2.5.4.16 


20 
Table 0 


Phone 

3 * r^nnrantnnl n#%**s 


telephone string 


2.5.4.20 



2.4 X.50n Aliag^ 

X.500 also has the concept of 'aliases'. An alias object effectively points 
to another entry and thus provides an alternate name for that entry. Thus an 
"alias" flag is added to the Hierarchy Table. When an alias is discovered during 
1 0 Navigation (i.e. the supplied DN contains an alias), then the alias value must be 
read from the Object Table. This alias DN must be resolved to where the alias 
points before Navigation of the original entry can continue. 

An innovation is to use an "aliased EID" column or A_EID to store "where" 
the alias "points to". This removes the need to repeatedly navigate through an 
1 5 alias. 
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2.5 X.50Q Data Tn^ mnrft 

Every X.500 attribute has a (internationally defined) syntax. X.500 

attribute syntaxes define how each attribute should be treated. In all string 

syntaxes (e.g. Printable, Numeric etc.) superfluous spaces should be ignored. In 
5 some syntaxes the case is not important (e.g. Case Ignore String and Case 

Ignore List) and so the names "Chris Masters", "Chris MASTERS" and " ChRis 

MaSTeRS " are considered identical. 

In order to do comparisons (e.g. search for a particular value), the syntax 

rules can be applied to create a normalized form (e.g. "CHRIS MASTERS"). If 
10 this normalized form is stored in the database, then any variations in input form 

are effectively removed, and exact matching can be used (which is necessary 

when using SQL). 

Both the normalized data and "raw" data are stored in the database. The 
"raw" data is necessary so that users can retrieve the data in exactly the same 
5 format as it was originally input. Thus the "Name" column in the Hierarchy Table 
becomes the "NameRaw" and a "NameNorm" column is added. Similarly, the 
"Value" column in the Object Table becomes the "ValueRaw" and a "ValueNorm" 
column is added. 

Hierarchy Table 



20 



EID 


Parent 


Path 


Alias 


A_E!D 


NameNorm 


NameRaw 


10 


0 


10. 


0 


0 


DATACRAFT 


Datacraft 


30 


10 


10.30. 


0 


0 


CHRIS, MASTERS 


Chris, MASTERS 


31 


10 


10.31. 


0 


0 


ALANA, MORGAN 


Alana, MORGAN 


35 


10 


10.35. 


1 


31 


SUPPORT ENGINEER 


Support Engineer 
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Object Table 

j AID j VIP | Disfing 



EID 



Value Norm 



ValueRaw 



Attribute Table 



r 



AID 



i 



Type 



Syntax 



ObjectID 



Table 3a Conceptual Table Design 

The example hierarchy shown in Table 3b will be used to illustrate these 
services. Each name in the diagram represents an object entry in the database. 
The triangle represents an alias entry, and the dotted line represents the 
connection between the alias entry and the object that it points to. The numbers 

1 0 next to each entry are the entry EID's. 

In the example, entry "1" has an RDN with a value of "Datacraft", entry "1 1" 
has an RDN with a value of "Sales", entry "20" has an RDN with a value of 
"Network Products" and entry "31" has an RDN with a value of "Alana Morgan". 
The DN of entry "31" is made up of a sequence of RDN's, namely. ""Datacraft", 

15 "Sales", "Network Products", "Alana Morgan". 

The alias entry "Datacraft/Networks" points to the entry "Datacraft", 
"Sales", "Network Products". When navigating to this entry the navigate process 
would find the alias entry, then find the DN of the object pointed to by the alias 
and then navigate from the root to the object entry returning an EID of "20" and a 

20 path of "1.11.20.". 



alias 




[ Datacraft 








11 




Sales 




20 




Network 
. Products 



111 



Marketing 



30 



| Chris Masters I 



[31 [32 
|] Alana Morganj [ Peter Evans ] 



Table 3b: Entry Tree 
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Distinguished ^mftfi 

For the entry shown in the sample Object Table (Table 3d) two of the 
attributes, commonName and surname, are distinguished values (or naming 
values) which combine to form the RDN for the entry. This RDN is stored in the 
5 Hierarchy Table. 

Multi-valueri Attrih.^ 

In X.500, it is permissible for an attribute to be multi-valued. The VID 
column is used to distinguish between values for an attribute. In the sample 
Object Table, the telephoneNumber attribute is multi-valued. 
10 3.1 Manning Serves tn .^QJ 

Attribute Ty pes and Values 

Any data supplied by an X.500 service is supplied as a list of Objectld's 
and their associated values. These must be converted into AID'S (using the 
Attribute table) and normalized values (using the Object table) for use by the 
1 5 X.500 application. The database returns data as AID'S and Raw Values, which 
must then be converted into Objectld's and their associated values in the X.500 
result. 

3.1.2 Navigation 

Each X.500 service supplies a Distinguished Name which is converted 
20 into an EID for use by the X.500 application. When the application processes a 
service it returns one or more EID's. These EID's can then be translated back 
into Distinguished Names in the X.500 result. 

All X.500 services rely on navigating the directory tree. To navigate to a 
particular entry, the following procedure is performed: 
!5 • Given the DN for the entry, locate the entry in the hierarchy table which 
has an RDN equal to the first RDN in the DN. 
Store the EID. 

Recursively, locate the entry which has an RDN equal to the next RDN in 
the DN and a parent equal to the stored EID. 
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Examnlfl 

Compare the telephone Number "03 727 9256" with the entry 
"Datacraft/Sales/Network Products/Chris Masters". 
Navigate to the entry and then; 
5 select VALUERAW from OBJECT 

where EID = 30 
and AID = 20 

and VALUENORM * "03 727 9456" 
If a value is selected then return "matched" else return "not matched". 
10 3.1.5 List 

Navigate to the required entry. Store the EID. In the Hierarchy Table, 
return the RDN's for all rows with a parent matching the stored EID. 
Example 

List from the entry "Datacraft/Sales". 
1 5 Navigate to the entry and then; 

select NAMERAW from HIERARCHY 
where PARENT =11 
3.1.6 Add Fntry 

Navigate to the required parent entry. Store the EID of the parent. Add a 
20 new EID to the Hierarchy table and add rows to the Object table for each value 
in the new entry. 
Example 

Add a new entry under the entry "Datacraft/Sales/Network Products". 

Navigate to the entry and then; 
25 insert into OBJECT 

(EID, AID, VID, DISTING, VALUENORM, VALUERAW) 
values (33, 3, 1, 1, EDWIN MAHER, Edwin Maher) 

and 

insert into HIERARCHY 
30 (EID, PARENT, PATH, ALIAS, A-EID, NAMENORM, NAMERAW) 

values (33, 20, 1.1 1.20.33..0 ,0 , EDWIN MAHER, Edwin Maher) 
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3.1.9 Modify RDM 

Navigate to the required entry. Check that the new name (RDN) does not 
exist in the current level of the subtree (i.e. that the new DN is distinct). Store the 
EID. Modify the entry in the Hierarchy and Object tables. 
5 Example 

Modify the RDN of the entry "Datacraft/Sales/Network Products/Chris 
Masters" to "Christine Masters". 
Navigate to the entry and then; 

select EID from HIERARCHY 
10 where PARENT = 20 

and VALUENORM = "CHRISTINE MASTERS" 
If no entries are returned then the new RDN may be inserted. First set the 
old RDN to be a non-distinguished value, 
update OBJECT 
15 setDISTING = 0 

where EID = 30 and VALUENORM = "CHRIS" 

and 

update HIERARCHY 

set NAMENORM = "CHRISTINE MASTERS" and 
20 set NAMERAW = "Christine Masters" 

where EID = 30 

and 

insert into OBJECT 

(EID, AID, VID, DISTING, VALUENORM, VALUERAW) 

25 values (30, 3, 1 , 1 , "CHRISTINE", "Christine") 

3.2 Search Strategy 

The most powerful and useful X.500 service is the search service. The 
search service allows an arbitrary complex filter to be applied over a portion of 
the Directory Information Tree (the search area). 
30 • A filter is a combination of one or more filter items connected by the 

operators AND, OR and NOT. For example; surname = "MASTERS" AND 

title = "SALES MANAGER" 
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the subtree and then apply the filter to all entries that have a path which is 
prefixed by the path of the base object (for example; to search for all entries 
under "Sales" we perform a search where PATH LIKE 1.11 .%). 
Base Obierrt fiftamfr 

5 Navigate to the base object. Store the EID. In the Object Table, read 

nominated values from rows which match the stored EID where a filter criteria is 
satisfied, eg, telephone prefix = "727". 
Example 

Search from the base object "Datacraft/Sales/Network Products" for an 
10 entry with surname = "MORGAN", using a "base-object-only" search. 

Navigate to the base object and then; 

select AID, VALUERAW from OBJECT 
where EID = 20 and AID = 4 

and NAMENORM = "MORGAN" 

15 One Levpl Rflflrrh- 

Navigate to the base object. Store the EID. Return the list of EID's which 
have a parent EID matching the stored EID (in Hierarchy table) and have values 
which satisfy the filter criteria (OBJECT table). In the Object Table, read 
nominated values for the returned EID's. 

20 Example 

Search from the base object "Datacraft/Sales/Network Products" for an 
entry with surname = "MORGAN", using a "one-level-only" search. 
Navigate to the base object and then; 

select H.EID from HIERARCHY H, OBJECT O 
25 where PARENT = 20 and AID = 4 and NAMENORM = "MORGAN" 

and H.EID = O.EID 
then place the EID's returned into an EIDLIST and 
select AID, VALUERAW from OBJECT 

where EID in [EIDLISTJ 
30 Subtmfi Rfla^; 

Navigate to the base object. Store the EID. Return the list of all EID's with 
a path like that of the base object (Hierarchy table) and have values which 
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the filter is applied. They also restrict the search area in that any dereferenced 
aliases are excluded from the search area. 
Aliases anrl Onpl .evel Saarrh 

If aliases are being dereferenced as part of a one level search and an 
5 alias entry is found then the alias must be resolved (using the Object table or the 
A_EID ). The aliased object is then added to the search area to which the filter is 
applied. In a oneLevel search where aliases are found the search area will 
consist of non-alias entries directly subordinate to the base object and all 
dereferenced aliases. 
10 Aliases and Subtree fiPflrch. 

If aliases are being dereferenced as part of a whole subtree search and 
an alias entry is found then the alias must be resolved (using the Object table or 
the A_EID) and this EID must then be treated as another base object, unless it is 
part of an already processed sub tree. 

15 When dereferencing aliases during a search the "Path" column can be 

used to find alias entries within a subtree join. If an alias entry is found that 
points outside of the current subtree then the subtree pointed to by the alias can 
also be searched for aliases. One property of the hierarchical tree structure is 
that each subtree is uniquely represented by a unique base object (i.e. subtrees 

20 do not overlap). When performing a subtree search we build up a list of base 
objects which define unique subtrees. If no aliases are found then the list will 
contain only one base object. If an alias is found that points outside of the 
subtree being processed then we add the aliased object to the list of base 
objects (unless one or more of the base objects are subordinate to the aliased 
25 object in which case the subordinate base object(s) are replaced by the aliased 
object). The search area will therefore consist of non-alias entries that have a 
path prefixed by the path of one of the base objects. 
4. LOGIOAI DFfiMnN 

Whilst the Conceptual Design (see Table 4a) is sufficient to implement 
the X.500 functionality, further performance improvements can be made. 
Hierarchy Table 



30 



| EID 


| Parent j 


Path 


| Alias 


A_EID 


Name Norm 


NameRaw I 
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ATTR 

| A.D | SYNTAX | DE SC | OBJE CTID 1 

Table 4b - Logical Design ~ ' 

4.1 Servinft p ftffffrT » m j|. T , n 

5 The practical reality for most RDBMS's is that big tables with many 

columns do not perform as well as smaller tables with fewer columns. The major 
reasons are to do with indexing options, I/O performance and table management 
(see Sections 4.5 and 4.6). This is why prior art relational design techniques 
aim to focus primary information into separate tables and derive secondary 
10 information via table joins (i.e. normalization and fragmentation techniques). 

One innovation in achieving X.500 performance is to decompose the 
tables around primary service relationships and derive secondary services via 
joins. This process is called service decomposition. The following 
considerations are made: 

15 (1) Columns that have strong relationships are preferred to be kept 

together (to avoid unnecessary joins); 
(2) If the number of significant rows in a given column is independent 
of the other related columns, then that given column is a candidate 
for a separate table. 

If a column is only used for locating information (input) or only used 
for returning results (output) then it is a candidate for its own table. 
(4) If a column is used as a key for more than one service then it is 
preferred to be a primary key and therefore in its own table (each 
table can have only one primary key). 

Keys are preferred to be unique or at least strong (non-repetitious). 



20 (3) 



25 (5) 
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NameNorm = "DATACRAFT") is the basis for Navigation and update checking 
(checking for the existence of an object before an Add or ModifyRdn). Acting on 
entries that have a given parent is used during List or OneLevel Search. Thus 
the DIT (Directory Information Tree) table has information required for 
5 Navigation, but allows its PARENT column to be used by other services. 

| HP j PARENT I ALIAS 



Table 4.2b - DIT Table 



RDN 



An object is differentiated from its siblings via its Relative Distinguished 
Name (RDN). RDN's are returned for a List (in conjunction with a given Parent) 
10 or as part of a full Distinguished Name (Read, Search). Thus the NAME table 
has information required for returning names (the raw RDN). 
F&5 



RAW 

Table 4.2c - NAME Table 



An object's absolute position in the hierarchy is necessary for building 
15 DN's (from which the raw RDN's are retrieved) and for expanding subtrees 
during Search. Thus the TREE table has information about an entry's Path (the 
sequence of EID's down from the root). 



| E'P " | path ~~ 1 

Tahla if trt TDCr T_ l_i _ I 



Table 4.2d - TREE Table 
20 Alias information is cached so that every time an alias is encountered 

during Navigate it does not have to be repeatedly resolved. Thus the ALIAS 
table only contains entries that are aliases. It is also used during OneLevel 
Search (in conjunction with the DIT Parent column) and Subtree Search (in 
conjunction with the Path column) to determine if there are any aliases in the 



25 search area. 


| EID A_EID j 


Table 4.2e - ALIAS Table 




Obiect Table DecomDosition 




The Object table contains the following columns: 




30 j EID | AID VID J Disting ValueNorm 


ValueRaw I 


Table 4.3a - Object Table 



The Object Table essentially contains information for finding a particular 
value (e.g. AID = surname, ValueNorm = "HARVEY") and for retrieving values 
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fully indexed access. A composite index on both type and value may be 
required. 

One innovation of the table decomposition in the previous sections is to 
maximise the use of primary indexes across tables. This reduces the number of 
5 secondary indexes (i.e. they become primary indexes on their own table). 
Following is a list of the indexes for each of the six tables used in the logical 
design. 



Table 


Primary Key 


Secondary Index 


CMT 


PARENT, RON 


EID 


NAME 


EID 




TREE 


PATH 


EID 


SEARCH 


AID, NORM 


EID, AID, VID 


ENTRY 


EID, AID, VID 




ATTR 

ToKIa A C 


(cached) 





Table 4.5 - Table indexes for the Logical Design 



10 The table design means that many queries can be handled without joins, 

giving substantial performance improvement. 
The joins that are considered necessary are listed below: 

List - for returning the RAW-RDNs under a given object (DIT joined with 
NAME). 

1 5 • Search / Subtree - for finding EIDs that match a filter over a whole subtree 
(where the base object is not the root) (TREE joined with SEARCH). 
Search / OneLevel - for finding EIDs that match a filter one-level under the 
base object (DIT joined with SEARCH). 

Search / Aliases / Subtree - for finding all the aliases in a subtree (TREE 
20 joined with ALIAS). 

Search / Aliases / OneLevel - for finding all the aliases under a given 
object (DIT joined with ALIAS). 

Note that the above joins are first level joins (i.e. between only two 
tables). It is preferable not to use higher order joins. 
25 4.6 Input/ Output Pcrform^n /^ 

An innovation of decomposing tables around services, which increases 
the number of tables, is that the new tables are much smaller than the 
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5. LOGICAL MFTHOng 

This section describes methods of interrogating the Logical Design 
30 tables, with reference to Figure 2B. 

Throughout this section, each X.500 method is defined and illustrated 
5 with an example. Table 5a displays a small hierarchy tree which includes an 
alias reference. The corresponding Table contents are shown in Table 5b. 



9l 



Datacraft 



alias 




11 



Sales ] f 



1» 



Marketing 



20 



Network 
Products 



I 30 31 32 

[Chris Masters) [Alana Morgan) | Peter Evans ] 



Table 5a - Simple Hierarchy Tree 



DIT 



10 



EID 


PARENT 


ALIAS 


RON 


1 


0 


0 


DATACRAFT 


10 


1 


1 


NETWORKS 


11 


1 


0 


SALES 


12 


1 


0 


MARKETING 


20 


11 


0 


NETWORK PRODUCTS 


30 


20 


0 


CHRIS MASTERS 


31 


20 


0 


ALANA MORGAN 


| 32 


20 


0 


PETER EVANS 
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ATTRIBUTE 



AID 


SYX 


DESC 


OBJECTID 


0 


objectldentifierSyntax 


objectClass 


2.5.4.0 


1 


distinguishedNameSyntax 


aliasedObjectName 


2.5.4.1 


3 


caselgnoreStringSyntax 


commonName 


2.5.4.3 


4 


caselgnoreStringSyntax 


surname 


2.5.4.4 


7 


caselgnoreStringSyntax 


localityName 


2.5.4.7 


8 


caselgnoreStringSyntax 


stateOrProvinceName 


2.5.4.8 


9 


caselgnoreStringSyntax 


streetAddress 


2.5.4.9 


1 0 


caselgnoreStringSyntax 


organizatronName 


2.5.4.10 


11 


caselgnoreStringSyntax 


organizationalUnitName 


2.5.4.11 


12 


caselgnoreStringSyntax 


title 


2.5.4.12 


13 


caselgnoreStringSyntax 


description 


2.5.4.13 


16 


PostalAddress 


postalAddress 


2.5.4.16 


17 


caselgnoreStringSyntax 


postalCode 


2.5.4.17 


18 


caselgnoreStringSyntax 


postOfficeBox 


2.5.4.18 


20 


telephoneNumberSyntax 


telephoneNumber 


2.5.4.20 
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ENTRY 
EIO" 



AID 

IT 



VID 



RAW 



[2.5.6.4] 



10 
TF 



[Datacraft] 



[266-268 Maroondah Highway] 



17 



[3138] 



10 
IF 



[2.5.6.1] 



1 

T 



o 



[Datacraft / Sales / Network Products] 



11 
TT" 



[2.5.6.5] 



11 



[Sales] 



11 

7F 



13 



[Safes Department] 



0 
TT 



0 



[2.5.6.5] 



12 
IF 



I [Marketing] 



13 
~F" 



[Marketing Department] 



20 
FF 



I [2.5.6.5] 



11 
"TF 



[Network Products] 



20 
"FT 



! [Network Products Section] 



30 
"5F 



[2.5.6.7] 



[Chris] 



4 

IT 



\ [Masters] 



30 
~3F 



\ [Sales Manager] 



30 

FT 



20 



20 



[(03) 727-9456] 



[(018) - 042 671] 



| [2.5.6.7] 



31 
FT 



[Alana] 



[Morgan] 



31 
FT 



12 



I [Sales Support] 



32 
32 



20 



| [(03) 727-9455] 



[2.5.6.7] 



[Peter] 



32 

FT 



[Evans] 



12 



| [Salesperson] 



32 



20 



I ((03) 727-9454] 



Table 5b: Example Tables 

NOTE: [ .... ] indicates a binary encoding of the exact data entry value. 
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At this stage we discover that this entry is an alias. The Alias Table is 
checked to see if the EID of the alias has been cached. If this is the first time an 
attempt has been made to resolve this alias then the A_EID column in the Alias 
Table will be zero. For the purpose of discussion it will be assumed that this is 
5 the first time. 

To resolve the alias, the DN of the aliased object must be determined. 
This is stored in the "aliasedObjectName" attribute of the alias entry. The 
aliasedObjectName has an AID = 1 (from the ATTR table) and so the DN is 
obtained from the Entry Table (RAW value) where EID • 10 and AID = 1. 
10 In this example, the DN of the alias is "Datacraft / Sales / Network 

Products". This DN is resolved completely using the normal tree walking 
technique. The value of EID is 20. 

At this stage, navigation continues for the unresolved RDN's in the 
original DN, namely "PETER EVANS". The last step required is then: 
15 • Scan the DIT table for a row containing PARENT = 20 and RDN = 

"PETER EVANS". 

Once an alias has been resolved it can be added (cached) in the Alias 
Table. This table contains a reference, A_EID, to the aliased object. In the 
above example, an entry in the Alias Table with an EID of 10 would have an 
20 A_EID of 20. Once an alias has been cached a tree walk is no longer 
necessary to resolve the alias. 
Directory Paths 

When objects are added to the DIT table, a corresponding row is added 
to another table called the Tree Table. This table stores the list of the EID's 
25 which identify a "Path" to the object. 
Distinguish ed Names 

Most services require the distinguished name to be returned in the 
Service Result. Using the directory path from the Tree Table, a DN can be 
constructed from the RAW RDN values stored in the Name Table. 
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X.500 definition 



Argument 


Description 


Name 


A Distinguished Name 


EntrylnformationSelection 


The attributes and values to be returned (ie EIS) 


Common Arguments 




Result 


Description 


Entry Information 


The DN plus any attributes and values returned 


Common Results 





Method 

Perform a tree walk using the DIT table, resolving aliases if necessary. 
5 Obtain the base EID. 

Using PATH from the Tree Table and the RAW RDN's from the Name 
Table, build a DN. 

If EIS specifies no attributes or values, just return the DN. 
If EIS specifies ALL types and values, return the RAW values from the 
1 0 Entry Table for the matching EID. 

If EIS specifies selected types and values, obtain the AID'S from the 
Attribute Table and then return selected types and/or values for the 
matching EID . 

Example; 

1 5 Read the entry "Datacraft / Sales / Network Products / Peter Evans". 

EIS is set to: attribute Types = allAttributes, InfoTypes 
attributeTypesAndValues. 

Using the DIT table perform a Tree Walk traversing EID's 1, 11, 20 and 
32 for the normalised RDN's DATACRAFT, SALES, NETWORK PRODUCTS. 
20 PETER EVANS. The EID of the selected object is 32. 

Extract the PATH from the Tree Table for EID = 32. The PATH is 
1.11.20.32. 

Build aDN from the RAW values in the Name Table for EID's 1 , 1 1 , 20, 32. 
Using the Entry Table and the Attribute Table, for each matching EID; 
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If an alias is dereferenced, return the DN of the selected object, using the 
path from the Tree Table and the RAW RDN's from the Name Table. 
Example 

Compare the DN "Datacraft / Sales / Network Products / Peter Evans" 
5 with a purported AttributeValueAssertion of "title - [Salesperson]". 

Obtain the EID for the given DN using a TreeWalk. The EID of the 
selected object is 32. 

Using the Attribute table, obtain the AID for "title", ie AID = 12. 
Using the Search Table locate rows with EID = 32 and AID = 12 and test 
1 0 for "NORM = SALESPERSON". 

Return TRUE or FALSE depending on the outcome of this test. In this 
instance the result would be TRUE. 

Since no aliases were dereferenced, the DN of the entry is not returned. 
5.4 ListSprvjcft 

15 A list operation is used to obtain a list of immediate subordinates of an 

explicitly identified entry. 



X.500 definition 



Argument 


Description 


Name 


A Distinguished Name 


Common Arguments 




Result 


Description 


DistinguishedName 


The DN of the selected object (returned if an alias 
is dereferenced) 


subordinates 


A list of RDN's for the subordinate entries (aliases, 
indicated by an alias flag, are not dereferenced) 


partialOutcomeQualifier 


An indication that an incomplete result was 
returned, eg, a time limit or size limit restriction. 


Common Results 





Method 

Perform a tree walk using the DIT table, resolving aliases if necessary. 
Obtain the EID of the base object. 
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X.500 definition 



Argument 


Description 


baseObject 


The Distinguished Name of the baseObject 


subset 


baseObject, one Level or wholeSubtree 


filter 


search conditions 


search Aliases 


a flag to indicate whether aliases among 
subordinates of the base object should be 
dereferenced during the search. 


selection 


EIS as for READ. The attributes and values to be 
returned. 


Common Arguments 




Result 


Description 


DistinguishedName 


The DN of the selected object (returned if an alias 
is dereferenced) 


entries 


Attributes & values (as defined in selection) for the 
entries which satisfy the filter. 


partialOutcomeQualifier 


An indication that an incomplete result was 
returned, eg, a time limit or size limit restriction. 


Common Results 





The search procedures for each search scope are outlined as follows: 
Base Object 

5 • Perform a tree walk using the DIT table, resolving aliases if necessary. 
Obtain the EID of the base object. 

Apply the filter to attributes and values in the Search Table with the EID 
of the selected object. 

If the filter condition is matched, return the Entry Information from the 
1 0 Entry Table. 

If an alias is dereferenced, return the DN using the Tree Table to extract 
the PATH and the Name Table to build the DN. 
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Example 

Perform a search on the baseObject "Datacraft / Sales" with: 
Scope set to WholeSubtree 

a Filter of "surname, substring initial = M". (Look for all surnames 
5 beginning with "M") 

SearchAliases set to TRUE. 

EIS set to attribute Types = allAttributes, InfoTypes = 
attributeTypesAndValues. 
Method 

0 Obtain the EID for the base object DN using a TreeWalk. The EID of the 

base object is "1 1 ". 

From the Tree Table, obtain the PATH for EID = 1 1 , ie, "1 .1 1 ". 
Check for any aliases among entries that have a path beginning with 
"1.11.". There are no aliases in this case. 
5 Obtain the AID for the attribute "surname" in the Attribute Table, ie, 4. 

Apply the filter and scope simultaneously, i.e. Using the Search Table, 
obtain a list of EID's from the target list where AID = 4 and the value begins with 
"M" joined with the Tree Table who's PATH is LIKE '1.11.%'. The matching 
EID's are 30 and 31. 
) Using the Entry Table and the Attribute Table, for each matching EID: 

return the OBJECTID's from the Attribute Table and the ASN.1 encoded 



RAW values from the Entry Table 


ie, 2.5.4.0, 


[2.5.6.7], 


2.5.4.3, 


[Chris], 


2.5.4.4 


[Masters] 


2.5.4.9 


[Sales Manager] 


2.5.4.20 


[(03) 727-9456] 


2.5.4.20 


[(018) -042 671] 


2.5.4.0 


[2.5.6.7] 


2.5.4.3 


[Aiana] 


2.5.4.4 


[Morgan] 


2.5.4.9 


[Sales Support] 


2.5.4.20 


[(03) 727-9454] 
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DIT 



EID 


PARENT 


ALIAS 


RDN 


33 


11 


0 


MARY DELAHUNTY 



NAME 

EID I RAW 

33 I [Mary Delahunty] 



5 TREE 



EID 


PATH " " 




J 33 


1.12.21. " 




SEAR 


CH 






EID 


AID 


VID 


DISTING 


NORM 




33 


0 


0 


0 


2.5.6.7 




33 


3 


0 


1 


DELAHUNTY 




33 


4 


0 


1 


MARY 


33 


12 


0 


0 


MARKETING MANAGER 


33 


20 


0 


0 


03 727 9523 


ENTRY 


f 




EID 


AID 


VID 


RAW 


33 


0 


0 


[2.5.6.7] " 


33 


3 


0 


[Delahunty] 


33 


4 


0 


[Mary] 


33 


12 


0 


[Marketing Manager] 


33 


20 


0 


[(03) 727-9523] 



5.7 Remove Entry fiervira 

A RemoveEntry operation is used to remove a leaf entry (either an object 
entry or an alias entry) from the Directory Information Tree. 
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X.500 definition 



Argument 


Description 


object 


The Distinguished Name of the entry to be modified 


changes 


A list of modifications 


Common Arguments 




Result 


Description 


NULL 


NULL 



Method 

Perform a tree walk using the DIT table. Obtain the EID of the selected 
5 object. 

For the selected object, perform one or more of the following actions: Add 
Value, Delete Value, Add Attribute, Delete Attribute 

The operations required for each action are as follows: 
Add Valiia 

10- If the attribute exists, add the value to the Entry Table and the Search 
Table. Checks are: If the attribute is single valued test for an existing 
value; if the attribute is multi-valued check for a duplicate value. 
Delete Valna 

For the Entry Table and the Search Table, if the value exists, delete it. A 
15 Distinguished Value cannot be deleted. 

Add AftrihntB 

If the attribute does not exist, add the Attribute Values to the Entry Table 
and the Search Table. 

Delfttft Attrihntp 

20 • For the Entry Table and the Search Table, if the attribute exists, delete it. 
Delete all values with AID = attr and EID = base object. Naming 
attributes cannot be deleted. 
Example 

Modify the Entry "Datacraft / Sales / Network Products / Chris Masters" 
25 with the following changes: 
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10 



Method 

Perform a tree walk using the DIT table. Obtain the EID and Parent EID 
of the base object. 

Using the DIT table, check for equivalent entries and return error if one is 
found. An equivalent entry has RDN = new RDN and PARENT = Parent 
EID. 

Using the Name Table, replace the old RDN with the new RDN. 
Using the DIT Table, replace the old RDN with the new RDN. 
Using the Entry Table, insert the new value. 

Using the Search Table, locate value = old RDN and set DISTING to 0. 
Insert the new value. 

If deleteOldRDN is set to TRUE the procedures following the Tree Walk 
are as follows: 

Using the DIT table, check for a sibling with the same name and an EID 
not equal to the base EID 

Using the Name Table, replace the old RDN with the new RDN. 
Using the DIT Table, replace the old RDN with the new RDN. 
Using the Entry Table, delete the old value(s) and insert the new 
value(s). 

Using the Search Table, delete the old value(s) and insert the new 
value(s). 
ExamnlB 

Modify the RDN of "Datacraft / Sales / Network Products / Chris 
Masters". The new RDN is "Christine Masters". 
25 deleteOldRDN is set to FALSE. 

The changes to the Tables will be as follows: 

DIT 



15 



20 



EID 


PARENT 


ALIAS 


RDN 


21 


11 


0 


CHRISTINE MASTERS 


NAME 


fcID 

I 21 


RAW 








| [Christine Masters] 





30 
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Time Limit indicates the maximum elapsed time, in seconds, within which 
the service shall be provided. Size Limit (only applicable to List and Search) 
Indicates the maximum number of objects to be returned. If either limit is 
reached an error is reported. For a limit reached on a List or a Search, the result 
5 is an arbitrary selection of the accumulated results. 
Abandon 

Operations that interrogate the Directory, ie Read, Compare, List and 
Search, may be abandoned using the Abandon operation if the user is no 
longer interested in the results. 
10 Aliases ft fiparch 

If an alias is encountered in a search and that alias points to a separate 
branch of the directory tree, then dereferencing of the alias requires: 
Navigation from the root entry to the referenced entry 
Searching of all Items subordinate to the referenced entry 
15 In the example shown in Table 5.10, if a WholeSubtree Search was 

performed on a base object of "Telco / Corporate / Data Services" the entries 
"Mervyn Purvis" and the alias "Strategic" would be searched. Strategic, 
however, points to a different branch of the tree which requires searching of the 
entry "Strategic" and all of its subordinates, ie, "Alan Bond", "Rex Hunt", "Wayne 
20 Carey" and "John Longmire". 
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Qptfmififi onpry Hfinrfling 

As the format of most services is known, many instances of these 
services can be resolved using static SQL statements. More complex services, 
such as searches with complex filters, can be resolved using dynamic SQL. 
5 This enables arbitrarily complex searches to be performed. 
Parallel niiPri ftR 

Also when processing search results the present system utilizes set 
orientation queries of SQL to avoid 'row at a time' processing. Thus search 
results may be assembled in parallel in memory. 
0 Data Stomp* 

The tables that store raw data store the data in ASN.1 format. This 
provides an efficient means of transfering data into or out of the database. 
Database TftTThninilftfr 

Complex services can be further improved by using the query optimiser, 

5 which provides a mechanism for reducing the time spent in resolving the query. 
The use of a relational database also provides an efficient use of memory and 
enables large databases to be constructed without the need for large amounts 
of memory being available. Many other X.500 applications cache the entire 
database in memory to achieve performance. This method consumes large 

0 amounts of memory and is not scalable. 
6. PHYSIC AL DEStfiN 

The physical design results from a process called physical transformation 
of the logical design. The physical design represents a preferred realization or 
embodiment of the logical design. Figure 2B and the tables below show one 

5 form of the physical design. New columns and tables are highlighted by double 
borders. 
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6.1 Effirifinrv 
INFOTahlft 

This table holds the highest EID value that has been used in the 
database. The inclusion of the INFO table enables the next EID to be obtained 
5 without any calculation of the maximum EID being performed by the database. 
This provides improved efficiency in adding entries to the database. More 
importantly the inclusion of the INFO table removes contention problems which 
may occur when multiple DSA's are adding entries at the same time. 
Shadow Keys 

10 Three tables have had shadow keys added. These are: 

a) The NORMKEY column in the SEARCH table. 

b) The RDNKEY column in the DIT table. 

c) The LEVI , LEV2, LEV3 and LEV4 columns in the TREE table. 
Each of these shadow key columns is a shortened version of a larger 

1 5 column. They have been added to shorten the indexes on each table. This 
gives improved performance for any queries that use the indexes and it also 
improves disk space usage as small indexes take up less space than large 
indexes. 

The shadow keys in the PATH table utilise the structured nature of the 
20 PATH. By being a composite key then exact matching can be used in the SQL 
instead of the "LIKE" operator. 

e.g. WHERE LEVI = 1 AND LEV2 = 10 AND ... 
instead of WHERE PATH LIKE '1 . 1 0.%'. 

If each of the LEV columns has their own index, then a sub-tree search 
25 needs to only use the base object, e.g. LEV2=10, since all objects under entry 
10 will have LEV2=10. 
SENTRY TaNft 

Some types of attribute values do not need to be normalised e.g. integer, 
boolean, date. Instead of storing them twice (SEARCH. NORM and 
30 ENTRY. RAW) they can be stored just once in a hybrid table called the SENTRY 
table. This reduces table sizes and increases storage efficiency at the cost of 
having to search two tables and retrieve from two tables. 
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also means that each value will have only one entry in the ENTRY table and 
that the ENTRY and SEARCH tables maintain their one-to-one correlation. 
Secondly the use of a BLOB table enables the application to make use of any 
database support for Binary Large Objects, (e.g. 64K Binary Columns). 
5 6.3 Functional Extensibility 
FLAGS Columns 

FLAGS column(s) are preferred to be added. These column(s) have 
been added to provide extensibility to the design. Specific values can be 
added to the flags as new functionality is required, without changing the table 
1 0 structure. 
Note: 

a) In the SEARCH table, the DISTING field may be absorbed into the 
FLAGS field. 

b) In the DIT table, the ALIAS field may be absorbed into the FLAGS 
15 field. 

The FLAGS column(s) may also provide a "summary" function for each of 
the tables. This means that the nature of an entry can be determined to some 
extent by checking the value of the FLAGS field. For example, a flag can be set, 
in the DIT table, when an entry is a leaf. Checking this flag is much simpler than 
20 checking for children of the entry. 

The FLAGS column can also be used to store security information, 
whether an alias points inside its parents sub-tree, whether a value is a BLOB, 
etc. 

7. EXAMPL F IMP1 F MENTATION 
25 The following provides an example of system performance and 

capabilities. It is to be understood that the present inventions should not be 
limited to the following disclosure. 
7.1 Overall syste m benefits 

The present invention is considered to provide enhanced performance 
30 over prior art implementations. Performance can be appraised in many ways, 
including: 
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Service 



Database Size (number of entries) 



Operation 
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100K I200K 



BIND 
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0.00 



I 0.00 



LIST 



level 1 
level 3 
level 4 



4 items 
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100 items 
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0.06 
0.22 



0.05 
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0.23 



0.05 
0.06 
0.23 



0.05 
0.06 
0.24 



0.05 
0.06 
0.23 



| 0.05 
0.06 
! 0.24 



READ 
SEARCH 



level 4 
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0.07 



0.07 
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0.07 
0.07 
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0.12 
0.15 
0.18 



0.09 
0.11 
0.29 
0.13 
0.16 
0.18 



0.09 
0.11 
0.28 
0.14 
0.17 
0.19 



0.09 
0.11 
0.29 
0.13 
0.18 
0.20 



0.09 
0.11 
0.26 
0.12 
! 0.18 
0.26 



full, equality 

full, no fitter, all-info 

full, no filter, all-info 



all entries, 1 hem 
all entries, 10 hems 
all entries, 100 hems 



0.08 
0.30 
36 



0.08 
0.74 
1.84 



0.08 
0.43 
1.50 



0.08 
0.59 
1.79 



0.08 
0.49 
82 



0.08 
0.67 
1.86 



ADD 



MODIFY 



full, initial 



all entries, 1 hem 



0.08 



0.08 



0.08 



0.08 



0.08 



level 5 
level 5 



100 sisters 



0.22 
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0.16 



16 
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Table 7A 
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6. All complex searches, in test, were performed in under one second. 
However, there may be some obscure searches (e.g containing 
combinations of NOT) which may not perform as well. 
Because this is a disk based system (rather than a memory based 
5 system) performance is essentially only dependent on the number of entries 
actually returned. It is relatively independent of the search complexity, the 
depth of the hierarchy, the number of attributes per entry or the types of 
attributes used in the query. In a "live" application of the system it may be 
possible to improve on the achieved test results by tuning the caching 
1 0 parameters, and by having a greater diversity of attributes. 



SUBSTITUTE SHEET (RULE 26) 



WO 96/07147 



PCT/AU95/00560 



73 

10. A method of searching an area in a database, the method comprising the 
steps of applying a filter and a scope. 

11. A method of searching an area in a database which includes aliases, the 
method comprising the steps of: 

expanding the search area by resolving aliases until a set of search 
areas is found; and 

applying a filter and a scope to the set of search areas. 

12. A method as claimed in claim 10 or 11, wherein the database uses 
X.500. 

13. A method as claimed in claim 10 ,11 or 12, wherein evaluating the filter 
and the scope is performed by single pass resolution. 

14. A method of implementing X.500 to a relational database, the method 
comprising: 

processing arbitrary data using a fixed set of queries / services. 

15. A method as claimed in claim 14, where the database is a relational 
database with SQL. 

16. A method as claimed in claim 15, where the database has 250,000 or 
more entries. 

17. A method of implementing X.500 on a relational database, the method 
comprising the step of applying functional decomposition to a property table. 

18. A method as claimed in claim 17, further comprising the step of service 
decomposition. 
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